\FloatBarrier
\section{ MPLS Fast Reroute}
\label{frr}
\graphicspath{{./figures/FRR/}}

MPLS FRR is a local restoration network resiliency mechanism that allows to protect lsp from link failure or node failure using a backup path.
The node which redirects the traffic onto the precalculated and presignaled backup path is called the Point of Local Repair (PLR). The node where a backup LSP merges with the primary LSP is called Merge Point (MP). 
There are two different types of local restoration:
\begin{itemize}
\item \textbf{one to one}: the point of local repair maintain a different backup for every lsp that pass through the node. The MP will receive packets with
different labels from every backup tunnel; the node must have different entry in his table for every lsp and their backup paths. 
The advantage is that the label stack does not increase but the drawback is the growth of entries in the merge point forwarding table. 
Sadly, the one to one local protection is not supported by OPNET, as one can read in the official documentation, and we could not perform any test.
\item \textbf{many to one}: the PLR mantain the same backup path for all the LSPs that goes through the protected facility and the same merge node.
In this case the MP must be the first node downstream to the protected link or node. 
The backup tunnel label is pushed on top of the protected LSP label at the PLR (label stacking), therefore the depth of the label stack increases when traffic is forwarded over the backup tunnel.
This solution has good scalability because many lsps use the same backup path.
The many-to-one backup is also called facility backup.
\end{itemize}

Now we present the scenarios implemented for the FRR facility backup.

\subsection{Scenario 1}

\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{FRR_setup.pdf} 
\caption{ Setup of the first FRR scenario.}
\label{fig:FRR_setup}
\end{figure}

In this scenario we used only one lsp from \textit{node\_0} to \textit{node\_3} and we protected the link \textit{node\_1 to node\_2} through a backup tunnel (the red one in Figure \ref{fig:FRR_setup}). 
In order to do so we had to specify the designed backup tunnel for the primary lsp and bind the interface of PLR on the protected link to the backup tunnel.
As we expected the traffic flow begin to use the backup tunnel just after the link failure. 
This rerouting operation is performed really fast;  opnet detected a reroute time of 0 seconds.
Obviously there is no setup time since rerouting is directly performed by the PLR.
Figure \ref{fig:FRR_failure} shows traffic and delay of IP packets in the network.

\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{paua_frr.pdf} 
\caption{ Traffic in the primary and facility backup LSPs compared with number of hops and delay. }
\label{fig:FRR_failure}
\end{figure}

\pagebreak
\subsection{Scenario 2}
\graphicspath{{./figures/FRR2/}}

\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{FRR2_setup.pdf} 
\caption{ Setup of the second FRR scenario.}
\label{fig:FRR_multiple_setup }
\end{figure}

The main difference from the first scenario is the presence of another LSP (the green one) passing through the link \textit{node\_1 to node\_2}. 
After the link failure, the traffic from both the lsps begin to flow in the backup tunnel. 
Then, in the merge point, packets go back to their original LSP (Figure \ref{fig:FRR_multiple_setup }).  

\begin{figure}[!htbp]
\centering
\includegraphics[width=\textwidth]{ffrr2_reroute.pdf} 
\caption{ Traffic rerouting of multiple LSP on a single facility backup.}
\label{fig:frr_multiple_failure}
\end{figure}

In figure \ref{fig:frr_multiple_failure} we can see that the traffic in the backup tunnel is the sum of the traffic in the two lsp. 
The reroute operation takes 0 seconds also in this case.